1. Field of the Invention
This invention relates to business process modeling and simulation, and particularly to scheduling token arrival in the business process modeling and simulation.
2. Description of the Related Art
In Business Process Modeling, simulation plays a vital role in evaluating and comparing the different alternatives prior to deploying those processes in a runtime environment. For a business to base its decisions on business process simulation, it is crucial that the business process simulation engine provide realistic information and benchmarks.
Process simulations may be used to observe a process in action, to examine the statistics that it generates as it runs, and to perform analysis on the simulation results. Changes to a process or to other model elements (such as available resources) may also be simulated and quantified with a comparative analysis of the before and after simulation result.
Simulation enables organizations to observe how a process will perform in response to variations of inputs to the process, just as in a real-life work environment. Simulation also provides the ability to vary process input volume over time by adjusting resources and current allocations. Simulation output provides detailed information regarding resource utilization levels and the results of cost and cycle-time calculations.
Within a simulation, a token represents a unit of work that is received by a process and transferred between different activities in the process flow. By specifying token creation settings, the quantity and rate of inputs that the process handles in a simulation run are defined.
For a process simulation to run, the process must receive one or more inputs. In a simulation profile, inputs to the process and to activities within the process are represented by tokens. Some tokens represent the transfer of data between activities, while other tokens represent only a transfer of control.
Token creation settings for any input that is associated with data, whether it is an input to a process or an input to an activity, within a process may be defined. The rate at which tokens are created for an input are determined by setting a time trigger. The time trigger can be a regular interval, or it may be a variable interval defined by a distribution.
The number of tokens to generate at one time (number of tokens per bundle), and a one time cost per token may also be defined. In addition, each of these attributes can be set to a constant value or to a variable value defined as a distribution may also be defined.
For example, to create tokens that represent the arrival of customers at a restaurant, one could use a normal distribution to specify an arrival interval, where five minutes is the mean and three minutes is the standard deviation. A weighted distribution list could be used for the number of tokens per bundle, to represent how many customers are in each party. In this example, the weighted distribution list enables setting of probabilities for each size of party, based on past experience.
By default, the token creation settings for a process in a simulation profile are set to the values specified in the local simulation preferences, except for the total number of tokens to generate. This value is instead derived from the minimum number of inputs as specified in the process model. This is done to prevent a situation in which the process cannot start because it does not receive the minimum number of inputs (which could be the case if the token creation settings in the local simulation preferences are a lesser value than the minimum number). You can also customize the token creation settings by changing them from their default values in the simulation profile.
Business process simulation engines in the marketplace base their token arrivals on a simple timetable where the user specifies the start time, end time, and number of tokens. In this way, the burden is put on the end-user to explicitly specify a table of constant point-in-times and associate each point-in-time with a constant number of tokens. Effectively, the end-user would have to fill a table like the one shown in Table 1.
TABLE 1Start TimeEnd TimeApr. 28, 2005 @ 1200 AMApr. 28, 2005 @ 0600 AMPoint-In-TimeNumber of TokensApr. 28, 2005 @ 12:00 AM10Apr. 28, 2005 @ 01:23 AM7Apr. 28, 2005 @ 4:51 AM12
However, it will be appreciated that many realistic business simulations require that token arrivals are based on a recurring time calendar with each recurring time interval—potentially—having a distinct distribution. Therefore a need exists for a token scheduler operating with a recurring time calendar.